Pipelines

Pipelines provide a streamlined method to manage the applications in your development lifecycle. With pipelines, you can auto-generate deployment plans and deploy applications versions to all environments.

A pipeline represents the environments and applications that you use to drive your development lifecycle. Environments are logical groupings for applications and tools. This process is intended to increase application quality before delivery to the target environment. A typical pipeline is shown in the following graphic:

Figure 1. Pipeline
pipeline
Pipeline features include the following items:
  • A pipeline represents the applications integrated into the value stream from HCL™ Launch or Jenkins.
  • The top row identifies the environments and provides tools to manage the environment.
  • Each column represents a logical environment.
  • The rows represent application versions. You can drill down to the underlying applications to view releases, history, or to troubleshoot.
  • You can use the play button at the top of an environment to manually start a deployment. By default, this action deploys all changed applications in parallel.
  • You can schedule deployments.
  • You can add gates to environments that require approval before application versions can run in the environment.
Note: Ongoing active pipeline improvements are in process for robust performance capabilities including the following:
  • Running deployments through the pipeline is documented here and there are gaps between the currently documented features and capabilities of these new plug-ins.
  • Externalizing new deployment CI/CD plug-ins integrating with HCL™ Accelerate.
  • Performing deployments using the HCL™ Launch and Azure DevOps plug-ins and greater flexibility.

Pipelines accept input from either source control management (SCM) repositories or other external applications, such as HCL™ Launch. When you create an environment, some default settings are set for you on the Input environment.

You add applications to the pipeline from external tools that are integrated with the product, such as Jenkins™. Jobs run serially; they enable flow control for your work. For example, you might run a job in a test environment before deploying to the production environment. You can ensure that if the tests fail, the deployment job won't run.

You can add gates to environments. A gate is a condition that must be met before jobs can run in the environment. For example, you might add a gate that requires an approval before a job can start.

You can define environment properties that can be used in all jobs. For example, you might define a TEST_URL property that passes a single URL to deploy and test jobs in a single environment. The deploy job would deploy to that URL, and the test job would test the running app at the URL.

Each pipeline environment automatically has a release and deployment plan associated with it. You do not have to manually create a release beforehand. As you add applications to an environment, a task is automatically added to the default deployment plan.

When you run a pipeline application, a deployment starts that uses the associated deployment plan. You can monitor the progress of the deployment with links provided on the stage card.